Компания VMware анонсировала новую версию платформы для создания отказоустойчивых хранилищ для виртуальных машин VMware vSAN 7.0 Update 1. Напомним, что о прошлой версии vSAN 7 мы писали вот тут.

Данная версия vSAN сфокусирована на функциях по обеспечению эффективности датацентра, которые нацелены на увеличения возврата инвестиций в оборудование и программное обеспечение:

Новые возможности VMware vSAN 7 U1 можно разделить на 3 категории:

• Эффективность и производительность
• Упрощение операций с инфраструктурой хранения
• Интеграция с облачной инфраструктурой

1. Технология HCI Mesh

Главная из новых возможностей - это технология VMware HCI Mesh, которая позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов):

В такой схеме можно использовать несколько кластеров-клиентов для монтирования датастора, но надо соблюдать правило доступа: не более 64 хостов ESXi к одному датастору, включая хосты серверного кластера.

В такой конфигурации можно делать vMotion виртуальных машин между кластерами vSAN, но хранилище (Storage vMotion) при этом перемещать нельзя.

Также в топологии HCI Mesh можно использовать подход Full Mesh, когда один и тот же кластер выступает и клиентом, и сервером:

Подход Full Mesh позволит вам сбалансировать потребление емкости кластеров хранилищ. При этом есть ограничение: каждый серверный кластер может экспортировать не более 5 датасторов для клиентских кластеров, а каждый клиентский - монтировать не более 5 датасторов серверных кластеров.

Особенности технологии HCI Mesh:

• Минимальное число узлов кластера-клиента и кластера-сервера - 2 узла
• Технически Compute-only vSAN cluster (без своих датасторов) сейчас работает, но не рекомендуется к использованию и не поддерживается
• Поддерживается одновременное использование хранилищ Hybrid (SSD+HDD) и All-Flash одновременно

Небольшой обзор технологии:

2. Поддержка SMB для vSAN Native File Services

VMware расширяет службы vSAN Native File Services за счет поддержки протокола SMB. Он интегрирован с Microsoft Active Directory и поддерживает аутентификацию Kerberos. Таким образом, vSAN теперь поддерживает NFS (версии 3 и 4.1) и SMB.

3. Шифрование vSAN Data-in-Transit Encryption

Теперь в vSAN 7 Update 1 есть возможность шифрования при передаче данных между узлами кластера по протоколу TCP с использованием крипто-модуля FIPS-2. При этом вам не потребуется использовать Key Management Server (KMS).

Также надо отметить, что одновременное использование HCI Mesh и Data-in-Transit Encryption не поддерживается.

4. Техника SSD Secure Erase

В vSAN 7 Update 1 появился надежный способ удаления данных с SSD-дисков. Пока это поддерживается только для оборудования Dell и HPE. Например, это можно будет использовать для готовых серверных узлов vSAN Ready Nodes и комплектов DellEMC VxRail.

5. Общая оптимизация производительности

Как и всегда, VMware проводит работу над улучшением vSAN в контексте производительности. Заявляется, что vSAN 7 Update 1 работает примерно на 30% быстрее при выполнении операций, чем vSAN 6.7 U3 (который до этого был самым производительным).

6. Возможность использования компрессии без дедупликации

Ранее vSAN позволял использовать две этих технологии только вместе, а сейчас можно использовать только сжатие данных, не нагружая вычислительные ресурсы движком дедупликации. Теперь технология работает так:

Дедупликация

• На уровне дисковой группы
• Работает при дестейджинге данных на capacity tier
• Работа с фиксированными блоками 4 КБ

Компрессия

• Работает после дедупликации, но до того, как данные дестейджатся
• Если блок можно сжать до 2 КБ или менее, то он сжимается
• Иначе сохраняется блок 4 КБ

Компрессия работает значительно быстрее дедупликации, поэтому ее отдельно удобно использовать для OLTP-нагрузок.

7. Функция Enhanced durability при выполнении операций обслуживания

Если хост ESXi находится в режиме обслуживания (maintenance mode), то vSAN теперь имеет механизм защиты данных, которые в этот период находятся только в одном экземпляре (у них был задан failures to tolerate равный 1, а а хост перевели в режим обслуживания - и теперь есть только одна активная реплика данных).

В таком случае vSAN понимает, что у вас был FTT=1, и на время обслуживания все операции записи начинает дублировать на выделенный хост для delta writes, чтобы вы не потеряли данные во время отказа хоста с единственной копией данных:

При выходе хоста ESXi из режима обслуживания происходит обновление его данных с временного хранилища, после чего оно высвобождается для дальнейшего использования. Интересно, что для этих целей можно использовать и witness-хост.

Данный механизм можно использовать как для RAID Mirroring, так и для Erasure Coding.

8. Быстрая перезагрузка и ускоренный апгрейд кластеров

• Существенное ускорение апгрейда кластеров за счет более быстрой перезагрузки хостов
• Метаданные хоста записываются на диск перед перезагрузкой и восстанавливаются в память после загрузки - это ускоряет актуализацию метаданных
• Как результат - хосты загружаются до 5 раз быстрее

9. Общий witness-хост для нескольких кластеров

Это очень удобно для ROBO-инсталляций. vSAN 7 Update 1 поддерживает до 64 кластеров в двухузловых конфигурациях с общим witness для ROBO-сценариев (это решения для удаленных офисов и филиалов - Remote or Branch Offices).

10. Оптимизация всегда доступной емкости (Slack Space)

По рекомендациям VMware нужно было всегда держать 25-30% свободной емкости хранилищ в кластере. Это называлось Slack Space. Теперь это называется Reserved Capacity, и ее необходимый объем зависит о числа узлов в кластере (чем меньше узлов - тем меньше емкость), например:

• 12 node cluster = ~16%
• 24 node cluster = ~12%
• 48 node cluster =~ 10%

Эта емкость нужна для:

• Операций Resync при изменении политик, ребалансировке, перемещении данных (Operations Reserve)
• Активностей Rebuild при отказах хранилищ и хостов (Host Rebuild Reserve)

Надо понимать, что Reserved Capacity предотвращает только развертывание новых виртуальных машин, но не затрагивает ввод-вывод уже имеющихся.

Также Reserved Capacity - это опциональный механизм, который не включен по умолчанию:

Функция vSAN Reserved Capacity не поддерживается для растянутых кластеров и двухузловых конфигураций.

11. Улучшения vSphere Lifecycle Manager (vLCM)

Еще в vSAN 7 поддерживались узлы Dell и HPE для решения vLCM, теперь же к ним добавилось и оборудование Lenovo ReadyNode.

Сам vLCM получил следующие улучшения:

• Работа с vSAN Fault Domains, двухузловыми конфигурациями и растянутыми кластерами (Stretched Clusters)
• Предпроверки Hardware compatibility pre-checks
• Параллельное обновление кластера до 64 хостов
• Поддержка окружений с NSX-T 3.1

12. Упрощенная маршрутизация для некоторых топологий

Раньше для топологии vSAN с внешним witness должны были иметь статическую маршрутизацию. Теперь в vSAN 7 Update 1 можно добавить шлюз по умолчанию и не прописывать статические маршруты:

13. Утилита vSAN I/O Insight

С помощью этого средства можно анализировать I/O-паттерны для анализа рабочих нагрузок в кластере. Это утилита, встроенная в vSphere Client, в которой доступен большой набор паттернов метрик и гистограмм для анализа таких вещей, как R/W ratio, Seq/Random ratio, 4K aligned / unaligned ratio, IO size distribution.

Все это позволяет не пользоваться сторонними утилитами для решения узких проблем, а понимать их природу прямо из vSphere Client:

14. Улучшения сервисов для Cloud native applications

• Платформа vSAN Data Persistence - это новый фреймворк для партнеров, который позволяет интегрировать информацию о приложениях для операционных задач через API.
• SAN Direct Configuration - это альтернативный способ для прямой интеграции сервисов с хранилищами vSAN.
• Улучшения интеграции с vSphere with Tanzu за счет расширений для томов гостевых кластеров TKG, а также получения информации о состоянии томов TKG supervisor и guest.

Доступность для загрузки VMware vSAN 7 Update 1 ожидается в самое ближайшее время, следите за нашими новостями.

Некоторое время назад мы писали о сервисах технической поддержки VMware Skyline (и тут). Напомним, что это проактивная технология VMware для предоставления расширенной технической поддержки некоторым клиентам для продуктов VMware vSphere.

На днях VMware аноснировала новую полезную утилиту Skyline Health Diagnostic Tool, с помощью которой пользователи смогут взаимодействовать с технической поддержкой вендора (GSS) и совмесно работать над возникающими проблемами в техническом ключе.

С помощью утилиты SHD вы сможете более эффективно работать с персоналом GSS, анализируя логи с помощью лог-бандлов для различных решений, и получать рекомендации об оптимизации виртуальной инфраструктуры:

Проще говоря, Skyline Health Diagnostics for vSphere - это утилита самообслуживания, которая позволяет идентифицировать проблемы с помощью лог-бандлов и получить ссылки на помогающие статьи VMware KB. Самое интересное, что утилита Health Diagnostics for vSphere доступна абсолютно бесплатно (за сам сервис Skyline, конечно же, надо платить).

Те из вас, кто использовал Skyline, знают, что есть такое средство Skyline Advisor, которое выполняет схожие (на первый взгляд) функции. Так зачем же нужен Skyline Health Diagnostic Tool?

Во-первых, Skyline Advisor - это облачный веб-сервис, а SHD - полноценный онпремизный тул для заказчиков. Ну а, во-вторых, Skyline Advisor - это тул для проактивной аналитики, а Health Diagnostic Tool сфокусирован на текущем анализе логов и решении проблем.

Управление утилитой Skyline Health Diagnostics происходит через веб-интерфейс виртуального модуля.

SHD выполняет следующие функции:

• На базе симптомов какой-либо проблемы представляет ссылку на Knowledge Base (где рассказано о ее исправлении), либо сразу выводит конкретные шаги по устранению трудностей.
• Механика самообслуживания ускоряет процесс самостоятельного нахождения причины проблем.
• Быстрое приведение инфраструктуры в соответствие с помощью конкретных рекомендаций позволяет оперативно устранить неполадку без нарушения процессов бизнеса.

Установка продукта разбита на 3 простых шага:

Более подробно об установке Health Diagnostic Tool рассказано вот тут, а сам процесс разобран в видео ниже:

Апгрейд виртуального модуля происходит в рамках простого рабочего процесса: надо просто зайти в Settings-> Upgrade & History.

С помощью SHD логи можно анализировать в двух режимах:

• Online - можно соединиться с сервером vCenter Server или ESXi и собрать логи. В рамках одной задачи анализа можно обрабатывать до 32 хостов.
• Offline - можно руками загрузить логи в формате .TGZ или zip-файла (когда отчеты сгенерируются, они будут доступны для скачивания.

Загрузить VMware Skyline Health Diagnostic Tool можно по этой ссылке. Документация доступна тут.

Коллега с virten.net написал замечательную статью об использовании сетевых адаптеров USB на хостах VMware ESXi, основные моменты которой мы приведем ниже.

Напомним, что подключить сетевые адаптеры USB на хостах ESXi можно с помощью драйвера USB Network Native Driver for ESXi, о котором мы не так давно писали вот тут. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Еще один вариант использования таких адаптеров - когда у вас (например, на тестовом сервере) есть всего один гигабитный порт, а вам нужно тестировать технологии и продукты, где нужно несколько высокоскоростных соединений.

Итак, после того, как вы скачаете драйвер, его установка делается одной командой:

# esxcli software vib install -d /path/ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip

На VMware ESXi 7 можно использовать фичу "component":

# esxcli software component apply -d /path/ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip

С помощью PowerShell можно создать кастомизированный образ ESXi с уже вшитым драйвером сетевого USB-адаптера. Просто раскомментируйте строчку с нужной версией драйвера:

# ESXi 7.0 Image with USB NIC Fling 1.6:
$baseProfile = "ESXi-7.0.0-15843807-standard"   # See https://www.virten.net/vmware/vmware-esxi-image-profiles/ for available Image Profiles

$usbFling = "ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip"        # Uncomment for ESXi 7.0

#$usbFling = "ESXi670-VMKUSB-NIC-FLING-39203948-offline_bundle-16780994.zip"  # Uncomment for ESXi 6.7

#$usbFling = "ESXi650-VMKUSB-NIC-FLING-39176435-offline_bundle-16775917.zip"  # Uncomment for ESXi 6.5
Add-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Export-ESXImageProfile -ImageProfile $baseProfile -ExportToBundle -filepath "$($baseProfile).zip"

Remove-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Invoke-WebRequest -Method "GET" https://download3.vmware.com/software/vmw-tools/USBNND/$($usbFling) -OutFile $($usbFling)

Add-EsxSoftwareDepot "$($baseProfile).zip"

Add-EsxSoftwareDepot $usbFling

$newProfile = New-EsxImageProfile -CloneProfile $baseProfile -name $($baseProfile.Replace("standard", "usbnic")) -Vendor "virten.net"

Add-EsxSoftwarePackage -ImageProfile $newProfile -SoftwarePackage "vmkusb-nic-fling"

Export-ESXImageProfile -ImageProfile $newProfile -ExportToIso -filepath "$($baseProfile.Replace("standard", "usbnic")).iso"

Export-ESXImageProfile -ImageProfile $newProfile -ExportToBundle -filepath "$($baseProfile.Replace("standard", "usbnic")).zip"
 

При установке VMware ESXi на хост, где есть только USB сетевые адаптеры, процесс может зависнуть на 81%. В этом случае почитайте вот эту статью.

Кстати, ваши USB-адаптеры лучше всего пометить наклейками. Автор предлагает указать имя хоста ESXi, MAC-адрес адаптера и его номер vusbX:

Номер виртуального vusbX не сохраняется при перезагрузках. Начиная с версии драйвера 1.6 можно закрепить MAC-адрес за нужным vusbX. Сначала найдем наш адаптер:

# esxcli network nic list |grep vusb |awk '{print $1, $8}'

vusb0 00:23:54:8c:43:45

vusb1 a0:ce:c8:cd:3d:5d

Затем сделаем статический маппинг адаптеров с использованием модуля vmkusb_nic_fling:

# esxcli system module parameters set -p "vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d" -m vmkusb_nic_fling

В данной команде нужно перечислить все адаптеры через пробел (если вы вызываете ее второй раз, то нужно переуказать каждый из адаптеров, иначе маппинг сбросится).

Далее нужно проверить маппинги с помощью команды:

# esxcli system module parameters list -m vmkusb_nic_fling
Name                        Type    Value              Description
--------------------------  ------  -----------------  -----------
usbCdromPassthroughEnabled  int                        Enable USB CDROM device for USB passtrough: 0 No, 1 Yes
vusb0_mac                   string  00:23:54:8c:43:45  persist vusb0 MAC Address: xx:xx:xx:xx:xx:xx
vusb1_mac                   string  a0:ce:c8:cd:3d:5d  persist vusb1 MAC Address: xx:xx:xx:xx:xx:xx
vusb2_mac                   string                     persist vusb2 MAC Address: xx:xx:xx:xx:xx:xx
vusb3_mac                   string                     persist vusb3 MAC Address: xx:xx:xx:xx:xx:xx
vusb4_mac                   string                     persist vusb4 MAC Address: xx:xx:xx:xx:xx:xx
vusb5_mac                   string                     persist vusb5 MAC Address: xx:xx:xx:xx:xx:xx
vusb6_mac                   string                     persist vusb6 MAC Address: xx:xx:xx:xx:xx:xx
vusb7_mac                   string                     persist vusb7 MAC Address: xx:xx:xx:xx:xx:xx

Если вы хотите сделать текущий маппинг постоянным, то используйте команду:

# esxcli system module parameters set -p "$(esxcli network nic list |grep vusb |awk '{print $1 "_mac=" $8}' | awk 1 ORS=' ')" -m vmkusb_nic_fling

Также статические маппинги можно сделать и через PowerCLI. Выводим адаптеры:

PS> Get-VMHostNetworkAdapter -VMHost esx2.virten.lab -Physical -Name vusb* |select Name,Mac 

Name  Mac

----  ---

vusb0 00:23:54:8c:43:45

vusb1 a0:ce:c8:cd:3d:5d

Настраиваем маппинги MAC-адресов:

PS> get-vmhost esx2.virten.lab | Get-VMHostModule vmkusb_nic_fling | Set-VMHostModule -Options "vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d"
 

Проверяем результат:

PS> get-vmhost esx2.virten.lab | Get-VMHostModule vmkusb_nic_fling |ft -AutoSize

  Name             Options

  ----             -------

vmkusb_nic_fling vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d

Тестируем производительность адаптеров

В тесте используются три типа адаптеров на хосте ESXi:

• Intel NUC embedded NIC (подключен к физическому коммутатору)
• 1 Gbit StarTech USB NIC (подключен к физическому коммутатору)
• 2.5 Gbit CableCreation (кросс-соединение между хостами)

Измеряем задержки (latency) с помощью пинга (50 штук):

# ping [Address] -c 50

Результат:

Далее тестируем пропускную способность (bandwidth) с помощью iperf3. Для этого нужно сделать копию бинарника утилиты:

# cp /usr/lib/vmware/vsan/bin/iperf3 /usr/lib/vmware/vsan/bin/iperf3.copy

Запускаем сервер на первом ESXi:

# /usr/lib/vmware/vsan/bin/iperf3.copy -s

Далее запускаем клиент на втором ESXi. Тест идет 5 минут (300 секунд) с сэмплами каждые 10 секунд:

# /usr/lib/vmware/vsan/bin/iperf3.copy -i 10 -t 300 -c [SERVER-IP]

Результат:

Далее проводим операцию vMotion виртуальной машины между хостами ESXi. Результат таков:

Очевидно, кросс-соединение на адаптерах 2.5G рулит.

Проверка совместимости

Не все сетевые адаптеры USB поддерживаются нативным драйвером. Их актуальный список всегда можно найти вот тут. Вот эти адаптеры точно работают:

Адаптеры доступны в форм-факторах USB-A и USB-C. Между ними есть переходники.

Если вам нужно высокоскоростное соединение (multi-gigabit) между несколькими хостами, можно посмотреть на следующие коммутаторы:

• MikroTik CRS305-1G-4S+IN ($130 USD) - 4 порта
• MikroTik CRS309-1G-8S+IN ($260 USD) - 8 портов
• Netgear MS510TX ($260 USD) - 10 портов
• TRENDnet TEG-30102WS ($450 USD) - 10 портов

Самое быстрое и дешевое соединение между двумя хостами ESXi - соединить адаптеры патч-кордом напрямую:

Проверяйте параметр MTU size, когда включаете Jumbo Frames

Если вы меняете размер MTU на виртуальном коммутаторе, он принудительно меняется на всех подключенных к нему физических сетевых адаптерах. Имейте в виду, что эти адаптеры должны поддерживать выставляемый MTU size.

Посмотреть размер MTU можно следующей командой:

[root@esx4:~] esxcfg-nics -l
Name    PCI          Driver      Link Speed      Duplex MAC Address       MTU    Description
vmnic0  0000:00:1f.6 ne1000      Up   1000Mbps   Full   00:1f:c6:9c:47:13 1500   Intel Corporation Ethernet Connection (2) I219-LM
vusb0   Pseudo       uether      Up   1000Mbps   Full   00:24:9b:1a:bd:18 1600   ASIX Elec. Corp. AX88179
vusb1   Pseudo       uether      Up   1000Mbps   Full   00:24:9b:1a:bd:19 1500   ASIX Elec. Corp. AX88179

В данном примере MTU size настроен как 1600, что подходит для адаптеров (и работает для сети NSX-T). Если же вы поставите его в 9000, то увидите в vmkernel.log ошибки для dvSwitch о том, что такой размер не поддерживается устройством:

2020-07-19T16:10:42.344Z cpu6:524356)WARNING: vmkusb: Set MTU 9000 is not supported: Failure
2020-07-19T16:10:42.344Z cpu6:524356)WARNING: Uplink: 16632: Failed to set MTU to 9000 on vusb0

Если вы хотите проверить корректность вашего MTU size, то можно использовать команду ping с размером пакета MTU-28 байт (8 байт на заголовок ICMP и 20 байт на заголовок IP). Таким образом, для MTU size 1600 используйте число 1572:

[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1572 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1572 data bytes
1580 bytes from 192.168.225.10: icmp_seq=0 ttl=64 time=0.680 ms

[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1573 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1573 data bytes
sendto() failed (Message too long)

Источник статьи.

Это статья нашего спонсора - компании ИТ-ГРАД, предоставляющей в аренду виртуальные машины из облака. Гиперконвергентность – быстрорастущий сегмент СХД. Переход от традиционной архитектуры к HCI выбирают все больше компаний. Хотите узнать почему? В статье мы ответим на этот вопрос и расскажем для каких задач подходит VMware vSAN...

Иногда в кластере хранилищ VMware vSAN случается такая ситуация, что один из хостов ESXi оказывается "пустым", то есть не содержит компонентов виртуальных машин. При этом хранилища остальных хостов в кластере могут быть загружены почти полностью.

В этом случае надо посмотреть на интерфейс vSphere Client в разделе vSAN health check - там может быть такое сообщение для проблемного хоста:

vSAN node decommission state

Означает это, что хост находится в режиме обслуживания с точки зрения vSAN (Node Decommission State). При этом, например, с точки зрения хостов ESXi кластера VMware vSphere / HA он может не быть в maintenance mode. Поэтому может сложиться впечатление, что хост просто не принимает дисковые объекты по каким-то причинам.

Это состояние рассинхрона кластера vSphere и кластера vSAN. Лечится следующей командой по SSH, которая выведет узел vSAN из режима обслуживания, после чего он оживет на прием компонентов:

localcli vsan maintenancemode cancel

Также вы можете кликнуть правой кнопкой на хосте ESXi, перевести его в режим обслуживания, а потом вернуть обратно:

Это отменит и перевод в режим обслуживания vSAN, после чего хост сможет размещать дисковые объекты виртуальных машин (для этого надо запустить операцию Rebalance). Более подробно об этом в KB 51464.

В конце августа компания VMware объявила о скором выпуске решения vRealize Operations 8.2, предназначенного для управления и мониторинга виртуальной инфраструктуры. Напомним, что о прошлой версии vROPs 8.1 мы писали вот тут.

В новой версии vROPs 8.2 появилось очень много всего нового, особенно связанного с созданием единой инфраструктуры для управления и мониторинга виртуальных машин и контейнеров из единой консоли. Давайте посмотрим на все это вкратце:

1. Функции Application-Aware Troubleshooting

В vROPs в последнее время быстро развиваются возможности для мониторинга инфраструктуры приложений в виртуальных машинах и контейнерах за счет пакетов Application Performance Management (APM) management packs. Это позволяет дополнить средства мониторинга компонентов инфраструктуры точными метриками, получаемыми от приложений.

Вот так выглядят средства обнаружения приложений и их параметров в решении vRealize Network Insight в виртуальном датацентре, которые далее передаются в vRealize Operations:

vRNI обнаруживает приложения и их взаимосвязи через анализ сетевых потоков, что отлично дополняет инфраструктурный метод обнаружения со стороны vROPs.

Еще одно важное улучшение в этой категории - опция "near real-time monitoring", что позволяет собирать данные в 15 раз чаще, что близко к режиму реального времени:

2. Улучшения поддержки Kubernetes

Главное улучшение vRealize Operations 8.2 - это возможности автоматического обнаружения гостевых кластеров Tanzu Kubernetes:

Второе важное улучшение - это интеграция с Prometheus через специальный адаптер, который используется большинством разработчиков для сбора метрик с инфраструктуры кластеров Kubernetes.

Ну и Management Pack for Container Monitoring теперь переименован в "Management Pack for Kubernetes".

3. Интеграции с внешними системами

Помимо более глубокой интеграции с vRNI, решение vROPs 8.2 поддерживает целую экосистему интеграции с внешними системами и облачными технологиями. Это лучше всего иллюстрируется картинкой (интеграции доступны через соответствующие Management Packs):

Тут можно отметить следующие моменты:

• Management Pack for AWS будет включать в себя аналитику емкостей EC2
• В VxRail появится 140 новых алертов
• Существенно обновятся пакеты для SNMP, NSX-T и Skyline
• Новый management pack для Flowgate (о нем мы писали вот тут)
• vRealize Operations management pack for Horizon будет доступен только для vRealize Operations Cloud

Ну и в vROPs появятся средства True Visibility Suite от купленной компании Blue Medora, теперь они будут называться vRealize True Visibility Suite. Более подробная информация об этом появится чуть позже.

4. Простота использования

Во-первых, был существенно упрощен рабочий процесс управления политиками, с которым теперь значительно удобнее работать в интерфейсе vROPs 8.2. Все операции доступны в контексте выбранных объектов:

Во-вторых, был существенно переработан стартовый дэшборд, на котором теперь можно более интуитивно найти действия для выполнения задач:

Идея состоит в том, чтобы разделить объекты и рабочие процессы. Также разделы теперь категоризированы по типу возникающей задачи траблшутинга (доступность, нехватка ресурсов и т.п.) и разделены на уровне провайдера услуг и пользователей сервисов (ВМ и приложения):

5. Прочие улучшения

Тут можно отметить следующие наиболее важные вещи:

• Интеграция с vRealize Automation (Cloud и 8.2)
• Оценка потенциала оптимизации рабочих нагрузок (прогноз результата)
• Скачиваемые отчеты об оптимизации рабочих нагрузок (workload optimization reports)
• Поддержка назначения цен для всех нагрузок (а не только vRealize Automation) с кастомизируемыми ставками
• Оценка затрат на уровне отдельных дней
• Улучшения в движке оценки стоимости ресурсов
• Метрики AWS CloudWatch API для гостевых ОС
• Увеличен масштаб для оценки корреляции метрик
• Новые страницы информации для vSAN
• Упрощенные представления контента (с функциями импорта и экспорта), а также простые представления настроек
• Кастомные шаблоны комплаенса для vRealize Operations Cloud
• Поддержка Cloud Director Service для vRealize Operations Cloud
• Новый регион Sydney для vRealize Operations Cloud
• vRealize Operations Cloud доступен на VMware Cloud Provider Hub

О доступности для загрузки VMware vRealize Operations 8.2, скорее всего, будет объявлено на предстоящем VMworld Online 2020.

Несмотря на то, что компания VMware представила версию средства для создания отказоустойчивых хранилищ vSAN 6.5 еще в 2016 году, многие крупные компании продолжают ей пользоваться. Между тем, надо понимать, что скоро браузеры отключат поддержку Flash, и все консоли на базе этой технологии (а именно на ней работает старый vSphere Web Client) просто прекратят работать (в Chrome это запланировано на декабрь этого года).

Чтобы вы могли и дальше использовать vSAN 6.5, нужно накатить патч vSAN 6.6.1 Patch 05 (вышел еще 30 июля), в котором добавлена поддержка технологии HTML5, поддерживающейся всеми современными браузерами. О возможностях vSAN 6.6.1 мы писали вот тут.

В новом апдейте vSAN 6.6.1 на базе мажорной версии 6.5 есть следующие нововведения:

• Отчеты о производительности вы можете найти в Cluster > вкладка Monitor > секция vSAN > Performance
• Добавлена панель общей информации в разделе Virtual object, показывающая размещение и доступность объектов в кластере. Также можно фильтровать список по статусу и типу объектов.
• В разделе Virtual Objects/ View data placement есть чекбокс "Group components by host placement", который дает возможность увидеть состояние компонентов данных и быстрее обнаружить потенциальные проблемы на хостах ESXi.

Также из блога VMware мы утянули вот такое видео с обзором интерфейса HTML5 для vSAN 6.6.1:

На днях компания VMware сделала анонс новых версий настольных платформ виртуализации Workstation 16 и Fusion 12. Напомним, что их обновления были анонсированы в продолжение технологических превью Workstation Tech Preview 20H1 (первая половина 2020 года) и Fusion Tech Preview 20H1. Сегодня мы поговорим о новых возможностях VMware Workstation 16.

С выходом новых версий поменялась и лицензионная политика. Теперь нет издания Standard, остались только Pro-версия и плеер. За $99 существующие пользователи могут переехать на новые версии Fusion Pro и Workstation Pro:

Стоимость новой лицензии для обоих продуктов стала $199 - это несколько дороже старых стандартных версий (особенно Fusion по $79), но вроде как это теперь Pro-версия для обеих платформ. Она стала дешевле для Workstation и дороже для Fusion.

Давайте теперь посмотрим, что нового появилось в VMware Workstation 16:

1. Поддержка контейнеров и Kubernetes

Для разработчиков, использующих контейнеры, появилась новая утилита командной строки - vctl. Ранее уже доступная в Fusion, она позволяет пользователям выполнять операции push, pull, build и run для образов OCI, а также развертывать локальные кластеры Kind на Kubernetes.

В дополнение к поддержке kind, vctl создает docker-совместимый сокет для kind без модификации контейнера за счет собственной имплементации containerd.

Также данная функция будет доступна и с Workstation Player.

Workstation 16 поддерживает запуск игр и приложений с Direct3D версии 11 (он же DirectX 11) или OpenGL 4.1. Пользователи могут выделить до 8 ГБ vRAM для гостевой ОС (для этого сама виртуальная машина должна иметь 16 ГБ или больше оперативной памяти).

Теперь поддерживаются соединения с ESXi 7 и vCenter 7 для управления виртуальными машинами, включая их перемещение между хостами и совместимость с инфраструктурой виртуальных ПК. Это доступно только в Pro-версиях.

4. Темная версия интерфейса

Теперь в Workstation 16 есть темная тема Dark Mode UI, доступная как в Pro, так и в Player. Эта версия отлично дополняет темную тему Windows 10 билд 2004.

5. Движок рендеринга графики в песочнице

Теперь есть новая функция Sandbox Renderer, которая позволяет отделить виртуальный графический движок, дав ему пониженные привилегии, что делает платформы Fusion и Workstation более безопасными.

На Workstation 16 для Linux теперь появилась поддержка Vulkan API. Теперь рендер может использовать DirectX 10.1 и OpenGL 3.3 даже на базе интегрированной карты Intel GPU.

7. Улучшенные специальные возможности

Теперь продукт соответствует стандарту VPAT Section 508 для лиц с ограниченными возможностями.

Теперь в Workstation поддерживаются виртуальные устройства USB 3.1, их можно пробрасывать в виртуальные машины с полной поддержкой драйверов. Кроме того, было сделано множество улучшений в плане производительности, безопасности, а также исправлено много багов.

Пользователи, купившие VMware Workstation 15.5 Pro или Workstation 15.5 после 15 августа, получат бесплатный ключ на Workstation 16. Доступность продукта ожидается уже в самое ближайшее время.

На днях компания VMware обновила пару продуктов линейки серверной платформы, выпустив обновления компонентов vSphere 6.7 Update 3:

Давайте посмотрим, что нового появилось в vCenter и ESXi:

• Поддержка SMTP-аутентификации в виртуальном модуле vCenter Server Appliance для отсылки алертов и алармов по почте в защищенном режиме. Можно также использовать и анонимный режим.
• Еженедельное оповещение о приближении устаревания сертификатов для служб vCenter Single Sign-On Security Token Service (STS). Напоминалки начинаются за 90 дней и появляются каждую неделю.
• Через Managed Object Browser можно сделать hard stop виртуальной машины на случай, если это невозможно сделать из гостевой ОС. Формат вызова такой: https://10.100.200.300/mob/?moid=vm-518&method=terminate
• Обновления базовой операционной системы Photon OS.

Release notes доступны тут.

В основном, этот релиз содержит исправления ошибок, среди которых есть и критические ошибки, приводившие к падению хоста ESXi. Полный список фиксов доступен в тут.

В основном, этот релиз содержит исправления ошибок, полный список фиксов доступен тут. Также обновился openssl до версии 1.0.2v. Пакеты VMware Tools для Windows подписаны сертификатами Microsoft на базе SHA-2.

В основном, этот релиз содержит исправления ошибок, полный список фиксов доступен тут.

Скачать VMware vSphere 6.7 Update 3 и обновленный vCenter 6.7 Update 3j можно по этой ссылке.

Производительность дисковой подсистемы в Linux зависит от различных параметров и настроек, одной из которых является тип планировщика для работы с потоком ввода-вывода (I/O scheduler). Если вы планируете использовать продукт StarWind VSAN for vSphere для создания программных хранилищ на базе виртуальных машин Linux (Virtual Storage Appliance), то информация ниже может быть вам полезна.

В зависимости от типа целевого хранилища, иногда целесообразно поменять используемый тип планировщика. Чтобы вывести текущий тип I/O scheduler, нужно выполнить следующую команду для выбранного устройства:

# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq

В данном случае мы видим, что тип планировщика - это noop (он же none). В зависимости от версии ядра Linux, он также может быть выставлен как mq-deadline. Кстати, обратите внимание, что тип планировщика указывается на уровне отдельного дискового устройства.

Считается, что для SSD и NVMe-устройств лучше ставить планировщик none / noop, который уменьшает нагрузку на CPU, а вот для HDD-дисков лучше использовать mq-deadline, который показывает лучшие результаты по итогам синтетических тестов.

Чтобы поменять планировщик на noop для диска sdb, нужно выполнить следующую команду:

# echo noop > /sys/block/sdb/queue/scheduler

Потом надо обязательно проверить, что планировщик поменялся, следующей командой:

# cat /sys/block/sdb/queue/scheduler
[noop] deadline cfq

Но это все меняет тип планировщика на время, до перезагрузки, чтобы вы могли проверить разные планировщики и сделать тесты производительности. Чтобы сохранить эти изменения, нужно изменить файл scheduler.rules в директории /etc/udev/rules.d/

Например, если вы хотите поменять планировщик на noop для устройства sdb и установить политику "no read ahead" для него, то нужно добавить туда следующую строчку:

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sdb", ATTR{queue/scheduler}="noop", ATTR{queue/read_ahead_kb}="0"

Рекомендуется выставлять одинаковый тип планировщика на всех узлах, где расположены хранилища StarWind VSAN. Также надо отметить, что последние версии продукта StarWind VSAN for vSphere при установке автоматически выставляют тип планировщика noop для SSD-хранилищ.

Это гостевой пост нашего спонсора - сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины из облака в аренду. Агенты Veeam Agents for Microsoft Windows и for Linux – это программы, входящие в экосистему решений Veeam. Они необходимы для резервного копирования и восстановления данных с физических устройств – серверов, рабочих станций, ноутбуков и другого поддерживаемого оборудования.

На сайте проекта VMware Labs появилась интересная штука для Data Scientist'ов - средство Federated Machine Learning on Kubernetes. Техника Federated Learning предполагает распределенную модель создания систем в области больших данных средствами машинного обучения, без необходимости расшаривать тренировочный датасет с централизованной ML-системой и другими пользователями.

Проще это понять на примере - есть такие задачи, где данные нужно обрабатывать ML-алгоритмами (например, предиктивная клавиатура Gboard от Google, которая, кстати, круче яблочной), но сами данные (набранные тексты) на центральный сервер передавать нельзя (иначе это нарушение пользовательской приватности). В этом случае распределенная система Federated Learning позволяет обрабатывать модели на оконечных устройствах. Координация тренировки моделей при этом может быть централизованная или децентрализованная. Примерами также здесь могут служить такие сферы, как кредитный скоринг, медицинские данные, страхование и многое другое, где есть большие данные и строгие правила их хранения и обработки.

Практическим воплощением принципов FL является фреймворк FATE, который поддерживается сообществом Linux Foundation. Компания VMware выпустила средство Federated Machine Learning on Kubernetes, которое позволяет быстро развернуть и управлять кластером Docker / Kubernetes, который содержит в себе компоненты FATE. В такой среде можно делать следующие вещи:

• Разрабатывать и тестировать модели в Jupyter с использованием технологий Federated Machine Learning
• Построить FATE-кластер с полным жизненным циклом обслуживания, в том числе на базе платформ MiniKube, Kubernetes on AWS/Google Cloud/Azure, VMware PKS и VMware Tanzu

Утилита командной строки, которая доступна в рамках данного средства, позволяет создать и развернуть весь FATE-кластер на базе уже готовой конфигурации, которую можно кастомизировать по своему усмотрению.

Для работы с Federated Machine Learning on Kubernetes можно использовать Docker 18+ / Docker-compose 1.24+, либо Kubernetes v1.15+, также вам потребуется Linux-машина для исполнения CLI-интерфейса утилиты. Загрузить данное средство можно по этой ссылке, документация доступна тут.

Компания VMware недавно сделала несколько обновлений в списке лабораторных работ Hands-On Labs (HoL) на базе платформы VMware Learning, добавив 18 новых лаб. Они посвящены vCloud Management Platform, то есть таким решениям, как vRealize Automation, vRealize Operations, Log Insight и прочим продуктам для управления и автоматизации облаков.

Ну и в других разделах тоже добавилось всего по мелочи:

Сами лабораторные работы списком (посмотреть и запустить их можно вот тут):

• HOL-2101-01-CMP - What's New in vRealize Operations 8.1
• HOL-2101-02-CMP - Getting Started with vRealize Log Insight
• HOL-2101-03-CMP - vRealize Operations- Optimize the Performance of Your vSphere Environment
• HOL-2101-04-CMP - vRealize Operations - Optimize and Plan vSphere Capacity and Costs
• HOL-2101-05-CMP - Troubleshooting and Remediation with vRealize Operations and Log Insight
• HOL-2101-06-CMP - vRealize Operations Advanced Topics
• HOL-2101-91-CMP - Getting Started with vRealize Operations - Lightning Lab
• HOL-2002-01-CMP - Wavefront by VMware - Real-Time Metrics Analytics
• HOL-2002-02-CMP - Network Insight and vRealize Network Insight - Getting Started
• HOL-2002-02-CMP - Network Insight and vRealize Network Insight - Getting Started
• HOL-2106-01-CMP - Getting Started with vRealize Suite Lifecycle Manager
• HOL-2106-02-CMP - Integrating the vRealize Suite Together
• HOL-2106-03-CMP - Configuring Multi-Tenancy for VMware Identity Manager and vRealize Automation
• HOL-2121-01-CMP - What's New in vRealize Automation 8.1
• HOL-2121-02-CMP - vRealize Automation for End Users
• HOL-2121-03-CMP - Administering vRealize Automation
• HOL-2121-04-CMP - Administering vRealize Automation - Advanced Use Cases
• HOL-2121-05-CMP - vRealize Automation for DevOps
• HOL-2121-06-CMP - Getting Started with vRealize Orchestrator
• HOL-2121-91-CMP - Getting Started with vRealize Automation - Lightning Lab
• HOL-2073-01-CMP - What's New in vRealize Operations Manager 8.0

Напомним, что бесплатные лабораторные работы VMware HoL позволяют освоить работу с различными продуктами и технологиями, проходя по шагам интерфейса. Такой способ отлично подходит для обучения работе с новыми версиями решений без необходимости их развертывания.

Некоторое время назад мы писали об анонсе новой версии платформы для виртуализации и доставки настольных ПК и приложений VMware Horizon 8. Буквально через несколько дней компания VMware объявила о доступности для скачивания этого продукта, а также подробно рассказала обо всех его новых возможностях. Сделаем это и мы...

На сайте проекта VMware Labs появились обновления сразу трех интересных утилит. Давайте посмотрим, что там появилось нового:

1. Обновление FlowGate 1.1.2

Напомним, что FlowGate представляет собой средство для агрегации данных из различных источников. Это middleware, которое позволяет провести агрегацию данных систем инвентаризации датацентров DCIM / CMDB и далее передать их в системы управления задачами инфраструктуры (например, vRealize Operations). 

Давайте посмотрим, что нового в версии FlowGate 1.1.2:

• Добавлена поддержка шасси (Chassis) в API-интерфейсе
• Добавлены данные PDU phase
• Обновлена версия Springboot с 1.4.7 на 2.3.7

Скачать FlowGate 1.1.2 можно по этой ссылке.

2. Новая версия Demo Appliance for Tanzu Kubernetes Grid 1.1.3

Напомним, что это виртуальный демо-модуль, с помощью которого администраторы платформ vSphere и Kubernetes могут протестировать инфраструктуру контейнеризованных приложений в виртуальных машинах.

Что нового в версии 1.1.3:

• Поддержка последнего релиза TKG 1.1.3
• Поддержка рабочего процесса апгрейда TKG Workload Cluster на K8s 1.17.9 с версии 1.18.6
• Утилита TKG Crash Diagnostic utility (для отладки падений) в составе виртуального модуля
• Утилита Helm (3.2.4), включенная в состав модуля
• Обновленные версии Harbor (1.10.3), Docker Compose (1.26.2), Kubectl (1.18.6), Octant (0.14.1) и TMC (d11404fb) CLI в составе виртуального модуля
• Сценарий PowerCLI для автоматизации проверок запуска TKG на VMware Cloud on AWS

Скачать Tanzu Kubernetes Grid 1.1.3 можно по этой ссылке.

3. Обновление VMware Machine Learning Platform 0.3

Эта платформа предоставляет инженерам по работе с данными различные возможности в области Data Science в рамках виртуальной инфраструктуры.

Что нового появилось в обновлении vMLP 0.3:

• Федерация сервисов на базе FATE
• Обновленная версия Istio 1.4.9
• Обновленная версия Horovod 0.19.2
• Апгрейд основных компонентов (MLflow 1.10.0, Pandas 1.0.3 и других)
• Улучшения стабильности
• Обновления документации

Скачать vMLP 0.3 можно по этой ссылке.

Как многие из вас знают, у компании StarWind, выпускающей лучший продукт Virtual SAN для создания программных iSCSI хранилищ под виртуализацию, есть и программно-аппаратный комплекс HyperConverged Appliance (HCA). Чтобы управлять этим решением в контексте всей инфраструктуры, существует продукт StarWind Command Center, на который мы сегодня посмотрим.

На днях компания Gartner обновила свой магический квадрант, касающийся расстановки сил среди решений для резервного копирования и восстановления данных современных датацентров (Data Center Backup and Recovery Solutions).

Давайте взглянем на Magic Quadrant для Data Center Backup and Recovery Solutions 2020:

И сравним его с квадрантом прошлого года, о котором мы писали вот тут:

Уже четвертый год подряд занимает в этом исследовании место лидера, а в этом году вырвалась на первое место по критерию способность реализации (ability to execute). Gartner отмечает следующие сильные стороны продуктов Veeam:

• Monitoring, reporting and diagnostics — средства Veeam Intelligent Diagnostics обнаруживают проблемы с производительностью и некорректными конфигурациями, которые можно автоматически исправить с помощью решения Veeam ONE.
• Licensing portability — опция Veeam Universal License позволяет гибко переназначать лицензии между гипервизорами, а также физическими и виртуальными средами, расположенными on-premise или в облаке.
• Comprehensive Microsoft Exchange and Office 365 support — бэкап и гранулярное восстановление окружений Microsoft Exchange, Microsoft SharePoint и Office 365 из единой точки в рамках унифицированного процесса.

Более подробно о решении Veeam Availability Suite можно узнать по этой ссылке. Бесплатную пробную версию продукта Veeam Backup and Replication для VMware vSphere и Microsoft Hyper-V можно скачать вот тут.

Четыре года назад мы публиковали табличку, которая показывает соответствие билдов различных продуктов VMware их официальным версиям (а до этого мы публиковали табличку 6 лет назад).

С тех пор много чего изменилось, в том числе добавились новые продукты, поэтому ниже таблица с нужными ссылками для соответствующих продуктов и датами релизов:

Все перечисленные ссылки агрегированы в KB 1014508.

Это гостевой пост нашего спонсора - компании ИТ-ГРАД, предоставляющей услуги аренды виртуальных машин VMware и сервисов Veeam из облака. Чем сложнее ИТ-инфраструктура, тем выше необходимость в ее контроле. Если за работой 2-3 серверов можно следить вручную, используя штатные средства (Windows monitoring, например, или самописные скрипты), то мониторинг сотни виртуальных машин требует автоматизированного решения. Veeam ONE – это универсальный инструмент для мониторинга и аналитики данных виртуальных, облачных и физических сред.

На днях компания VMware выпустила обновления сразу трех интересных утилит для виртуальной инфраструктуры на сайте проекта VMware Labs. Давайте посмотрим, что там интересного.

1. Обновился мобильный клиент vSphere Mobile Client до версии 1.13

Тут появилось не так много нового, но все же:

• Страница информации о датасторе - Datastore details page (туда можно перейти со страницы виртуальной машины)
• Исправлена ошибка с соединением к консоли ВМ отдельного хоста ESXi
• Исправлена ошибка, возникавшая при переключении между серверами

Скачать vSphere Mobile Client 1.13 можно по этой ссылке. О прошлой версии можно почитать у нас тут.

2. Обновилось средство App Volumes Entitlement Sync до версии 4.1

Оно позволяет прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках. После аутентификации на обеих площадках вы сможете выбрать права доступа, которые надо сравнить или синхронизировать.

Из нового:

• Можно получить версию App Volumes через API с возможностью получения номера билда
• Версия App Volumes 2006 и более поздняя имела проблему с Entitlement Sync 4.0 при возвращении строкового значения

Скачать App Volumes Entitlement Sync 4.1 можно по этой ссылке. Напомним, что про предыдущую версию Entitlement Sync 4.0 мы рассказывали вот тут.

3. Новая версия Power vRA Cloud 1.3

Напомним, что это средство позволяет отобразить сложное множество программных интерфейсов VMware vRealize Automation Cloud API в простой набор функций PowerShell. 

Что появилось нового:

• 4 новых командлета для VMC (VMware Cloud)
• 5 новых командлетов для AWS
• Поддержка Powershell 7 on Windows
• Исправления ошибок

Скачать Power vRA Cloud 1.3 можно по этой ссылке. О возможностях версии 1.1 можно почитать у нас вот тут.

Некоторые из вас знают, что есть такое решение VMware vRealize Network Insight (vRNI), которое предназначено для мониторинга и защиты сетевой инфраструктуры виртуальной среды VMware vSphere.

Администраторам виртуальной инфраструктуры часто приходится делать копии различных ее управляющих компонентов, в том числе vRNI. Сейчас VMware рекомендует делать резервную копию конфигурации vRNI на уровне всей виртуальной машины (см. KB 55829). Рекомендуется выключить ВМ с vRNI, скопировать ее целиком, а потом включить снова - это единственный поддерживаемый способ на данный момент.

Martijn Smit опубликовал интересный пост о том, что на самом деле у vRNI есть способ резервного копирования и восстановления конфигурации через API, для которого есть специальный API endpoint по пути /settings/backup:

Если посмотреть внутрь, то там можно увидеть вполне работоспособный механизм бэкапа конфигурации vRNI:

Используя API endpoint /api/ni/settings/backup, вы можете создать резервную копию конфигурации vRNI и перенаправить ее по SSH или FTP на бэкап-сервер в виде tar-файла со следующим содержимым:

Большинство этих файлов человекочитаемы, если вы откроете их в текстовом редакторе. Там находятся копии настроек приложений, объектов pinboards, data sources, сохраненный поиск, системные настройки (Syslog, SMTP и т.п.), пользовательские конфигурации и многое другое.

Для работы с конфигурациями vRNI через API Martijn сделал модуль PowervRNI. Вот пример использования сценария резервного копирования:

PS # $backupSchedule = @{ "enable" = $true; "schedule_period" = "DAILY"; "minute" = 30; "hour" = 12; "day_of_week" = 1 }

  PS # $sshServer = @{ "server_address" = "my-ssh-server"; "port" = 22; "username" = "vrni-backups"; "password" = "VMware1!"; "backup_directory" = "/home/vrni-backups/"; "backup_file_name" = "vrni-backup.tar" }

PS # Set-vRNIBackup -RunNow $true -BackupSchedule $backupSchedule -SSHServer $sshServer
config_filter

  -------------

  @{applications=True; snmp=True; smtp=True; data_sources=True; analytics_thresholds=True; analytics_outliers=True; events=True; syslog=True; pinboards=True; ldap=True; vidm=True; user_data=True; user_preferences=True; physical_subnet_v…
PS # Get-vRNIBackupStatus
status status_updated_timestamp

  ------ ------------------------

  IN_PROGRESS 1595425176027 Smit

  PowervRNI
  

Переменная $backupSchedule содержит в себе расписание резервного копирования, в примере выше она установлена на 12:30 (формат 24h) каждого дня.

Источник.

На сайте проекта VMware Labs обновилась утилита Horizon Reach до версии 1.1, которая позволяет проводить мониторинг и алертинг для развертываний VMware Horizon на площадках заказчиков (только в реальном времени, без исторических данных). Horizon Reach предназначен для тех окружений VMware Horizon, которые образуются в крупных компаниях на уровне площадок (Pod) в рамках концепции Cloud Pod Architecture как отдельный домен отказа (либо где площадки изолированы, но хочется иметь доступ к мониторингу в моменте из одной точки).

Это большое обновление, и в нем появилось много новых возможностей и исправлений ошибок прошлой версии (о которой мы писали осенью прошлого года вот тут).

Давайте посмотрим, что нового в Horizon Reach 1.1:

• Теперь утилитой можно напрямую мониторить компоненты Unified Access Gateways, также доступны функции скачивания конфигурации и логов
• Пользовательские сессии можно просматривать в рамках следующих представлений:
  • Pools
  • Farms
  • Unified Access Gateways
  • Global Entitlements
  • Global Application Entitlements
• Алармы были полностью переработаны, чтобы поддерживать отправку нотификаций в следующие каналы:
  • SMTP
  • Slack
  • Сторонние средства через сценарии PowerShell
• LDAP-интеграция алармов поддерживает кириллицу
• Улучшенный дэшборд алармов
• Обновления vCenter:
  • Хосты теперь видимы, и для них отслеживается производительность
  • Датасторы теперь видимы, показано свободное пространство
  • Кастеры теперь видимы, для них доступны различные представления - пулы, фермы и т.п. Также можно использовать интеграцию PowerShell и API
• Профили vGPU теперь показаны в представлении пулов
• Множество исправлений ошибок

Скачать VMware Horizon Reach 1.1 можно по этой ссылке.

Возможно, некоторые администраторы VMware vSphere попадали в ситуацию, когда один из датасторов в виртуальной инфраструктуре оказывался не привязанным ни к какому хосту ESXi, но при этом у него также была неактивна опция Delete Datastore из контекстного меню:

Paul Braren написал полезную инструкцию у себя в блоге о том, как решить эту проблему.

Такой зомби-датастор можно удалить только из базы данных vCenter Server Appliance (vCSA), поэтому вы полностью должны быть уверены в том, что он не используется никаким из хостов, а также в том, что он не презентует никакое физическое устройство в вашей инфраструктуре.

Первое что вам надо сделать - это включить доступ к vCSA по SSH (картинки - отсюда):

Далее нужно зайти по SSH на vCSA, запустить там шелл командой shell и далее запустить утилиту psql для работы с базой данных следующей командой:

/opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres

После этого нужно найти id датастора следующей командой:

Когда вы нашли id, нужно удалить упоминание об этом датасторе из таблиц базы данных vCSA следующими командами:

DELETE FROM vpx_ds_assignment WHERE ds_id=3089;
DELETE FROM vpx_datastore WHERE id=3089;
DELETE FROM vpx_vm_ds_space WHERE ds_id=3089;

При выполнении второй операции вы получите следующую ошибку:

ERROR: update or delete on table "vpx_datastore" violates foreign key constraing "fk_vpxspace"
DETAIL: Key (id)=(3089) is still referenced from table "vpx_vm_ds_space".

Не обращайте на нее внимания и выполняйте третью. Затем нужно перезагрузить vCSA и снова выполнить второй DELETE, который в этот раз должен завершиться успешно. После этого датастор пропадет из списка в vSphere Client.

Помните, что выполняя данную операцию, вы должны понимать, что именно делаете:)

На блогах VMware вышла отличная статья про безопасность виртуальных машин и виртуальной инфраструктуры VMware vSphere в целом, расскажем ниже ее основные моменты.

Как известно, одним из действенных способов атак на виртуальную инфраструктуру vSphere является проведение злоумышленником вредоносных действий из виртуальной машины, которая потом уничтожается, часто не оставляя следов и записанных действий. Еще один интересный способ со спецификой виртуализации - украсть виртуальную машину (например, контроллер домена) и ковыряться в ней уже в своей песочнице, чтобы вытащить нужную информацию.

Для предотвращения подобных типов угроз есть такие специализированные средства, как VMware Carbon Black, vRealize Log Insight и vRealize Network Insight, но базовые требования информационной гигиены нужно соблюдать и на уровне гостевых систем.

На этом уровне важной составляющей является пакет VMware Tools, имеющий широкие возможности доступа к виртуальной машине - ОС и приложениям. Управление поведением тулзов происходит с помощью вот этих утилит:

• C:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe (Windows)
• /usr/bin/vmware-toolbox-cmd (Linux)

Само собой приведенные ниже рекомендации - это руководство для параноиков (но, как говорит Эндрю Гроув - выживают только параноики), потому что безопасность, как вы знаете - это всегда компромисс между удобством и маниакально-призрачным ощущением защищенности.

И вот тут рекомендуется принять во внимание следующие факторы на уровне VMware Tools:

1. Отключить синхронизацию времени с хостом VMware ESXi

Время - очень важная категория в контексте безопасности. Оно важно для логов, для синхронизации событий аутентификации и прочего. По-хорошему, гостевая ОС должна получать время от NTP-сервера, а не от ESXi, который может быть скомпрометирован. Если вы сомневаетесь, что у вас настроено иначе, нужно принудительно отключить синхронизацию времени с хостом. Делается это следующей командой:

VMwareToolboxCmd.exe timesync disable

2. Отключить автообновление VMware Tools

Если у вас в компании принято, что рабочий процесс обновления системных компонентов должен быть унифицирован и контролироваться из одной точки, то можно отключить автоапдейт VMware Tools. Делается это так:

VMwareToolboxCmd.exe config set autoupgrade allow-upgrade false
VMwareToolboxCmd.exe config set autoupgrade allow-add-feature false
VMwareToolboxCmd.exe config set autoupgrade allow-remove-feature false

3. Отключить возможность кастомизации ОС при клонировании

Такая опция позволяет изменять параметры виртуальной машины и гостевой системы, что может быть выгодно злоумышленнику. Отключить кастомизацию ВМ можно следующей командой:

VMwareToolboxCmd.exe config set deployPkg enable-customization false

4. Контроль над информацией, предоставляемой через Appinfo

Об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы (по умолчанию сбор идет каждые 30 минут, это настраивается). 

Отключить Appinfo в виртуальной машине можно следующей командой VMware Tools:

VMwareToolboxCmd.exe config set appinfo disabled true

5. Отключить Guest Operations (оно же Invoke-VMScript)

Командлет Invoke-VMScript - это мощный механизм для разработчиков, позволяющий работать с гостевой системой виртуальной машины со стороны механизма сценариев PowerCLI. Очевидно, что этот интерфейс расширяет поверхность потенциальной атаки, и если вы им не пользуетесь, то его лучше отключить. Делается это следующей командой:

VMwareToolboxCmd.exe config set guestoperations disabled true

6. Отключение ненужных компонентов

Это базовое правило - чем меньше компонентов VMware Tools у вас установлено, тем меньше вероятность, что через какой-то из них произойдет атака. Например, не всем пользователям и администраторам нужны такие возможности, как Service Discovery, AppDefense и Shared Folders. Но здесь, очевидно, нужно соблюдать разумный баланс - не надо отключать что-то нужное, о чем вы потом будете думать: "почему оно не работает?".

Подробнее об отключении компонентов VMware Tools при развертывании через утилиту командной строки написано тут.

При описании новых возможностей VMware vSphere 7 мы рассказывали о функциях платформы, появившихся в результате приобретения VMware компании Bitfusion. Эти возможности позволяют оптимизировать использование графических процессоров GPU в пуле по сети, когда vGPU может быть частично расшарен между несколькими ВМ. Это может применяться для рабочих нагрузок задач AI/ML (например, для приложений, использующих PyTorch и/или TensorFlow).

Все это позволяет организовать вычисления таким образом, что хосты ESXi с аппаратными модулями GPU выполняют виртуальные машины, а их ВМ-компаньоны на обычных серверах ESXi исполняют непосредственно приложения. При этом CUDA-инструкции от клиентских ВМ передаются серверным по сети.

Технология эта называлась FlexDirect, теперь это продукт vSphere Bitfusion:

На днях это продукт стал доступен для загрузки и использования в онпремизных инфраструктурах.

Ключевыми особенностями vSphere Bitfusion являются:

• Возможность динамической привязки GPU к любой машине в датацентре, по аналогии с тем, как вы привязываете к ней хранилище.
• Возможность использования ресурсов GPU как одной машине, так и разделения его между несколькими. При этом администратор может выбрать, какой объем Shares выделить каждой из машин, то есть можно приоритизировать использование ресурсов GPU между потребителями.
• Возможность предоставления доступа как по TCP/IP, так и через интерфейс RDMA, который может быть организован как подключение Infiniband или RoCE (RDMA over Converged Ethernet). О результатах тестирования такого сетевого взаимодействия вы можете почитать тут.
• Передача инструкций к серверным машинам и обратно на уровне CUDA-вызовов. То есть это решение не про передачу содержимого экрана как VDI, а про высокопроизводительные вычисления.
• Прозрачная интеграция - с точки зрения приложений менять в инфраструктуре ничего не нужно.

Для управления инфраструктурой доставки ресурсов GPU используется продукт vSphere Bitfusion Manager, который и позволяет гибко распределять ресурсы между потребителями. Раньше он выглядел так:

Теперь же он интегрирован в vSphere Client как плагин:

Архитектура Bitfusion позволяет разделить виртуальную инфраструктуру VMware vSphere на ярусы: кластер GPU, обсчитывающий данные, и кластер исполнения приложений пользователей, которые вводят данные в них и запускают расчеты. Это дает гибкость в обслуживании, управлении и масштабировании.

С точки зрения лицензирования, решение vSphere Bitfusion доступно как аддон для издания vSphere Enterprise Plus и лицензируется точно так же - по CPU. Для других изданий vSphere, увы, этот продукт недоступен.

Скачать vSphere Bitfusion можно по этой ссылке. Документацию можно найти на странице продукта. Также Bitfusion интегрирован с инфраструктурой vSphere with Kubernetes, о чем можно почитать вот в этом документе.

Не все администраторы знают, что при апгрейде VMware ESXi на более новую мажорную версию есть возможность сохранить предыдущую конфигурацию гипервизора для возможности отката в случае неудачного обновления. Такая возможность, например, есть при апгрейде ESXi 6.5 на версию 6.7.

Для этого нужно во время установки выбрать пункт "Upgrade ESXi, preserver VMFS datastore". Под датастором тут имеется в виду, что на нем сохранится предыдущая установка ESXi:

Кстати, как видно из скриншота, можно сделать и свежую установку ESXi с возможностью отката к предыдущей версии.

Сделать апгрейд на ESXi 7 с сохранением предыдущей версии платформы не выйдет - в VMware vSphere 7 поменялась структура разделов гипервизора ESXi.

Итак, вы сделали апгрейд ESXi, но что-то пошло не так. Например, ваше железо больше не поддерживается (к примеру, CPU), и вам надо сделать откат к прошлой версии ESXi. Для этого во время загрузки вам нужно нажать комбинацию клавиш Shift + <R>:

После этого можно будет выбрать предыдущую версию ESXi и заменить ей новую установку, полностью откатившись к прошлому гипервизору и его настройкам:

Также можно делать бэкап и восстановление конфигурации VMware ESXi - об этом рассказано в KB 2042141.

Многие администраторы платформы VMware vSphere после выхода седьмой версии продукта обнаружили, что ESXi 7.0 больше не хочет устанавливаться на старом оборудовании. Так происходит с каждой версией VMware vSphere - старые драйверы убирают, новые добавляют - это нормальный цикл жизни и развития продуктов. Например, больше не поддерживаются следующие процессоры:

• Intel Family 6, Model = 2C (Westmere-EP)
• Intel Family 6, Model = 2F (Westmere-EX)

Однако для тех, кому очень надо, компания VMware оставила небольшую возможность все-таки установить ESXi 7.0 на старом железе со старыми процессорами, но без каких-либо гарантий по работоспособности и поддержке (то есть, статус у этого режима - unsupported). В частности, коллеги написали статью об установке vSphere 7 на сервер IBM M3 X3550 Series.

Для начала решили ставить ESXi на USB-диск, так как RAID-контроллер сервера больше не поддерживается со стороны ESXi 7:

Далее при загрузке установщика ESXi с CD-ROM или ISO нужно нажать комбинацию клавиш Shift + <O> (это буква, а не ноль), после чего появится приглашение ко вводу. Надо ввести вот такую строчку в дополняемую строку:

allowLegacyCPU=true

Далее для установки выбрали USB-диск и начали установку ESXi на него:

После того, как ESXi установится на ваш сервер, вам нужно будет снова нажать Shift + <O> и повторно вбить указанный выше параметр при первом запуске:

Теперь нужно сделать так, чтобы данный параметр добавлялся при каждой загрузке ESXi. Сначала включим сервисы командной строки ESXi и удаленного доступа по SSH. Для этого нужно запустить службы TSM и TSM-SSH на хосте ESXi:

Далее подключаемся к ESXi по SSH и с помощью следующей команды находим файл конфигурации загрузки:

find / -name "boot.cfg

Далее добавляем в него параметр allowLegacyCPU=true в разделе kernelopt:

Два загрузочных модуля ESXi находятся в директориях /bootbank и /altbootbank. На всякий случай надо поменять boot.cfg в обеих директориях.

С помощью команды cat выведите содержимое отредактированных файлов, чтобы убедиться, что параметры загрузки у вас будут сохраняться:

Ну и, собственно, сам сервер ESXi 7.0.0, нормально работающий на сервере IBM x3550 M3:

Бонусом шутка про редактор vi, которым редактировался файл boot.cfg:

Это спонсорский пост компании ИТ-ГРАД, предоставляющей услугу аренды виртуальных машин из облака по модели IaaS. Полгода назад мы запустили в коммерческую эксплуатацию сервис резервного копирования и восстановления данных, построенный на базе решения компании Акронис Инфозащита. Чтобы им могли воспользоваться компании самого разного масштаба, мы реализовали единое решение в рамках облачного направления МТС для клиентов «ИТ-ГРАД» и #CloudMTS. Пришло время подвести некоторые промежуточные итоги и поделиться...

Если вы следите за обновлениями VMware vSphere 7, то наверняка знаете, что не так давно уже выходили минорные обновления vCenter 7.0 Update 0a и vSphere with Kubernetes.

На днях VMware выпустила еще один небольшой апдейтик - vCenter 7.0.0b (на момент написания заметки дистрибутив еще недоступен для скачивания).

Давайте посмотрим, что там появилось нового:

• Новые алармы: vCenter Server 7.0.0b получил еще один аларм для vCenter Server Appliance, который срабатывает в случае, когда состояние репликации меняется на READ_ONLY. Аларм гасится, если состояние возвращается в Normal. С помощью этого аларма легко обнаружить проблемы в репликации между узлами vCenter на одной или нескольких площадках.
• C vCenter Server 7.0.0b можно использовать кнопку "Show only rollup updates", позволяющую отфильтровать и выбрать патчи, которые вы хотите включить в бейслайн для vSphere Lifecycle Manager. Кнопка доступна на вкладке Updates панели Lifecycle Manager. Также эта опция доступна в мастере создания нового бейслайна.
• Решено несколько проблем и исправлены некоторые ошибки. Посмотреть информацию о них можно тут.
• Про обновления движка VMware vSphere with Kubernetes рассказано здесь.

Скачать VMware vCenter 7.0.0b в составе vSphere 7 можно по этой ссылке.

Компания VMware недавно выпустила интересную бесплатную книгу "Micro-segmentation for Dummies Guide, 2nd Edition".

Те из вас, кто использует решение для сетевой виртуализации и агрегации трафика VMware NSX и средство обеспечения сетевой безопасности vRealize Network Insight, знают о таком подходе как микросегментация. С помощью него можно управлять сетевыми политиками на базе контекстов приложений - сетевом (на уровне 7 модели OSI), пользовательском (ID, сессия RDSH и прочее), а также рабочей нагрузки (тэги, группы безопасности).

Данная модель позволяет контролировать сетевой трафик на более гранулярном уровне, чем на уровне виртуальных машин и модулей Virtual Appliance, а также существенно повышает безопасность коммуникаций за счет принципа выдачи наименьших привилегий и фаерволлинга на уровне микросегментов.

Из книжки вы узнаете:

• Как разработать архитектуру защищенного датацентра на базе сетевой виртуализации и фаерволлинга на уровне рабочих нагрузок.
• Как микросегментация позволяет предотвратить распространение скрытых угроз в инфраструктуре датацентра.
• Топ 10 бизнесовых и функциональных преимуществ микросегментации.

Скачать книгу "Micro-segmentation for Dummies Guide, 2nd Edition" можно по этой ссылке.